The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
With the advent of computer systems, various techniques are evolving for storing and organizing electronic information. The most ubiquitous of these is the hierarchical file system. In a hierarchical file system, data is stored as a unit of data referred to as a file. Files are stored in persistent storage, such as a disk system. The files are hierarchically organized; a typical file system has directories arranged in a hierarchy, and documents that are contained in the directories.
Typically a file system is an integrated component of an operating system. The operating system provides functions for managing the files in the file system. For example, an operating system provides utilities for copying and deleting and controlling access to the files.
Repository
A repository is a computer system that stores and manages access to “resources”. Specifically, a repository is a combination of integrated software components and an allocation of computational resources, such as memory, disk storage, a computer, and processes on the node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to managing storage and access to resources.
A resource is a data source. The term resource encompasses a broad range of kinds of data sources. A resource can not only be a file, but also a XML document, including one stored in a file or stored in the tables of a relational database system. A resource may also be a CGI script, that, when executed, dynamically generates data.
Similar to a hierarchical file system, resources in a repository are organized according to a hierarchy referred to herein as a resource hierarchy. Each file may be located or identified by tracing a “path” through the hierarchy to the resource. For a given resource, a path begins at a root directory and proceeds down a hierarchy of directories to eventually arrive at the directory that contains the resource. A repository may associate more than one path with a resource.
A repository is typically part of a n-tier system, where the repository is in the first tier and one or more applications are in the outer tier. An application, as the term is used herein, is a unit of software that is configured to interact with and use the functions of a repository. In general, applications are comprised of integrated functions and software modules (e.g. programs comprised of machine executable code or interpretable code, dynamically linked libraries) that perform a set of related functions. The applications are configured to interact with a repository by establishing a connection to the repository through one or more interface components configured for interfacing to the repository. Often, but not necessarily, an application and repository are located on different computers; the connection to the repository includes a network connection to the repository.
Unlike a file system, a repository manages resources based on the content of the resource. For example, for a particular directory, a repository may only allow resources that contain certain types of data to be located within the directory, types such a XML document, or a XML document that conforms to a particular XML schema.
In addition, a repository may be customized through integration of business rules. Business rules are rules made by users of the repository for how a repository should manage resources on behalf of an application. Business rules include rules for how to respond to repository events, events such as accessing a resource, creating a resource in a particular directory, or moving a resource between directories. For example, a business rule may require that only documents with a particular content (e.g. XML documents, images) can be located at a particular directory. When a XML document is added to a particular directory, a business rule may require shredding a XML document (that is, break down the document into its constituent parts, e.g. elements, attributes) and store a representation of the document in an object-relational database system.
A repository may also integrate a more robust set of functions than is typically available with hierarchical file systems. A repository may provide the ability for versioning of resources, or a categorization engine that categorizes the resources.
Integrating Business Rules and Logic
Business rules are expressed by and/or implemented in business logic. Business logic refers to data, including code and instructions, that describe and/or define business rules and that control how the repository manages resources. Business logic is not native to the repository, but is instead supplied and/or input by users of the repository. Native code or data of a repository typically is developed by vendors of repositories.
There are various ways of integrating business rules and logic. The first is the single-application approach. Under this approach, one application, with unfettered access to a repository, substantially contains all the business logic for the business rules. For example, an application, with unfettered access to a repository, is configured to control what directories may be accessed by users or modules of the application. A drawback to this approach is that it does not facilitate sharing and partitioning access to the repository between multiple applications. Any application using a repository may access the resources of another application—a very undesirable situation from a security point of view.
This approach is also impractical to implement when use of third party applications is desired. It is impractical to customize a third party application in order to implement the business rules of a particular customer.
Another approach is the event-callout approach. Under this approach, a user supplies and registers callback routines that are called when certain repository events occur. The callback routines implement business logic and supply output values that indicate to the repository how the repository should manage or respond to the event. An advantage of this approach is its flexibility; a wide range of policies may be implemented using computer code. A disadvantage of this approach is its inefficiency. It involves a callout to a callback routine, which may reside within an application. Further, the repository, which has knowledge of how a repository is implemented, has no knowledge or control of how business logic is implemented in the callout routines, and is therefore unable to optimize how the repository is organized or optimize implementation and/or execution of business logic. Furthermore, the implementers of callback routines have limited knowledge of the repository design and configuration, and are less able to optimize callback routines for use with the repository.
Based on the foregoing, there is clearly a need for a new way to integrate business rules within a repository.